SGI Developer Toolbox 6.1/SGI Developer Toolbox 6.1 - Disc 4.iso/src/swtools/QnA-compilers

Text File | 1994-08-02 | 77.3 KB | 2,192 lines

                 ~4Dgifts/toolbox/src/swtools/QnA-compilers

  `!' indicates new or updated as of version 4.1

  This file contains Question-and-Answer messages saved out from internal and
  external newsgroups including comp.sys.sgi.graphics/comp.graphics.opengl/
  comp.sys.sgi.apps/comp.sys.sgi.misc/comp.sys.sgi/sgi.engr.all/sgi.engr.dev.
  while they are not necessarily *Frequently* asked questions, it is felt they
  potentially contain information useful to developers.

  This file includes QnAs relating to the area of compilers:


  # 1.  getting ugen error compiling even simple code in Fortran
! # 2.  is there a list of binary compat mode
        exceptions for 4.0.5 binaries running on 5.1?
  # 3.  Is it reasonable to expect that if __STDC__ is
        defined to be long double it will be supported?
  # 4.  'mkshlib' command:  trying to create a shared library
  # 5.  where did logname() go in 5.1 Irix?
  # 6.  why does fflush call itself so often?
  # 7.  when will I see 64 bits?
  # 8.  will SGI's C++ compiler include exception handling?
  # 9.  when were the C preprocessor symbols "sgi" & "_sgi" introduced?
  #10.  getting "undefined" errors again with C++ linking
  #11.  FORTRAN Intrinsic Function Generic Name. Is the Manual Wrong?
  #12.  Can one do Parallel processing without Power C?
  #13.  What the IRIX 64bit implementation be of
        variable declarations for c and c++ ?
  #14.  variable length arglist problem
  #15.  SGI's policy re:  the Delta C++ compiler?
  #16.  Usinit et al. disturbs real-time-ness
  #17.  how do i call a C++ member function from within dbx?
  #18.  Why does ld add -lX11_s when it sees -lgl_s ?
  #19.  lex question re: yywrap()
  #20.  R4000 and R4200 and instruction caching
  #21.  is there a way to link COFF & ELF objects together under 5.1?
  #22.  using "-D__STDC__=1":  struct sigcontext not included in compilation
  #23.  getting "illegal member use" ?
  #24.  trouble accessing /debug/nnnnn files via ioctl()
  #25.  Lisp still failing with ""contiguous jump problem" in 5.1
  #26.  can't find ELF object file access library
  #27.  strange messages from linker
        (vt_Atom_vts: both a large and small symbol)
  #28.  what is the current version for CC?
  #29.  Format of pixie(1) trace files?
  #30.  is there an already-compiled version of gcc for the SGI r4k?
  #31.  gp problem:  overflowing the "small-data" area
  #32.  accessing int, short, char bitfield and alignment issues
  #33.  assembly question:  version stamp
  #34.  how can I access/interpret the stack from within a program?
  #35.  ELF/COFF 4.0.5X compatibility library for 5.1.1?
  #36.  times when necessary to use the -static flag when compiling with f77
! #37.  what's the difference the abi and irix libs?






# 1.  getting ugen error compiling even simple code in Fortran
-------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (David B.Anderson)
Subject: Re: Fortran trouble
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 9 Sep 1993 17:05:23 GMT

In article <[e-mail]> Mike Whittaker <[e-mail]> writes:
>I am having trouble compiling even *very simple* code in fortran. I get
>a ugen error and a core dump. When I say simple, I mean
>    print*,'hello'
>    end
>That kind of simple. Any suggestions? I am running an R4k indigo with
>Irix 4.0.5F, fortran 3.4.1, and the 3.4.4 maintenance fortran release.

You've gotten an f77 and back end(uopt,ugen) which are mismatched.

See the output of:
versions -Ivb dev maint_dev ftn maint_ftn

What works:
f77 3.4.1 goes with dev/ido 4.0.1 ("2.40" compilers)
f77 3.5   goes with dev/ido 4.1   ("3.10" compilers) (replaced by 3.10.1)
f77 3.5.1 goes with dev/ido 4.1.1 ("3.10.1" compilers)

You may need to contact the support folks to understand the right
installation order to get things working again...






# 2.  is there a list of binary compat mode
      exceptions for 4.0.5 binaries running on 5.1?
------------------------------------------------------------
Newsgroups: sgi.engr.devp
Subject: Re: 4.0.5 to 5.1 compat issues...
Date: 22 Sep 1993 01:24:11 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 354

>ok, so is there a reasonbly exhaustive list of binary compat mode exceptions
>for 4.0.5 binarys running on 5.1?  if so, where can i get a copy?


This was recently posted to the various support mailing lists from
the back-line support group in CSD.  Have fun..


*****************************************************************************
            CUSTOMER SERVICES ENGINEERING
             FOR YOUR INFORMATION ONLY!
*****************************************************************************

                   IRIX4 Compatibility With IRIX5
                                by
                          Dave Frederick


------------------------------------------------------
Binary Compatibilty between IRIX5 and IRIX4
------------------------------------------------------

Almost all IRIX 4.0.X binaries will run on IRIX 5.x.   Because of
some restructuring of IRIX for SVR4 compliance, there are instances
where application code will need to be either recompiled or in some
cases recoded.  Instances where code changes are required include:

   - Programs which read from /dev/kmem will need to use /proc instead.

   - Programs that use /debug, like dbx and cvd (WorkShop), will need to
     use /proc instead.

   - Generally, any products that involve device drivers (e.g. add-on
     boards, some communications products) or other kernel components,
     such as STREAMS modules, must be re-released for IRIX 5.1.

   - Programs not compiled with shared versions of the libraries; for
     example, libfm.a and libgl.a instead of libfm_s.a and libgl_s.a.
     These programs would need to be relinked with the shared versions
     either under IRIX4 or the IRIX4 compatibility mode of IRIX5.

   - For execution on Challenge and Onyx systems, multi-processor programs
     that linked in libmpc.a (-lmpc) explicitly or that have been generated
     using the Power C or Power Fortran analyzers need to be re-linked under
     4.1.1 IDO on 4.0.5x IRIX or re-linked under IRIX4 compatibility mode on
     IRIX5 or fully compiled and linked using the IRIX5 compilers and libraries
     to take advantage of multiple processors on the new R4400 multiprocessor
     systems supported by IRIX5.  Executables of such programs operate
     correctly on IRIX5 Challenge or Onyx MP environments, but they run only
     on a single processor.  This is because new synchronization mechanisms
     are used on the R4400 MP systems.  Those with Power Series systems with
     IRIX5 installed will not need to relink MP binaries with -lmpc on IRIX5;
     4.0.x MP binaries will continue to work in MP fashion on ALL machines
     except Challenge and Onyx.

SVR4 ABI binaries will run without any changes.

------------------------------------------------------
Object Compatibilty between IRIX5 and IRIX4
------------------------------------------------------

Due to the new binary format used in IRIX 5.x, ELF, object files
created under IRIX 4.0.X (COFF format) cannot be linked with IRIX 5.x
compiled code.  Given the existence of many third party libraries
which will not have been compiled under 5.x, the compilers provide a
compatibility mode such that code compiled under 4.0.x can be linked
with other COFF format objects or libraries on a system running IRIX5.
Each of the compiler products except for Ada have an irix4_ version
of the product, for example the FORTRAN media comes with ftn and
irix4_ftn products.  The current Ada release, 6.2.1, only produces
COFF objects.  See the Known Bugs section of this document for a
list of known problems with compiling in IRIX4 mode on IRIX 5.0.1.
^L
* How to use and not use IRIX4 compatibility mode

In order to use the 'c' compiler in IRIX4 mode, the c *and* irix4_c
products need to be installed (located on the IDO cd).  The /usr/bin/cc
driver invokes the compiler stages with the correct paths when the
environment variable SGI_IRIX4 is set.

Correct usage of IRIX4 compatibility mode:
% setenv SGI_IRIX4 1
% /usr/bin/cc hello.c -v
/usr/irix4/usr/lib/acpp ...
% file a.out
a.out:          MIPSEB COFF executable (paged) not stripped - version 3.12
% unsetenv SGI_IRIX4
% /usr/bin/cc hello.c -v
/usr/lib/cfe ...
% file a.out
a.out:   ELF 32-bit MSB dynamic executable (not stripped) MIPS - version 1

If /usr/irix4/usr/bin/cc is invoked instead of /usr/bin/cc, say if
/usr/irix4/usr/bin is in the PATH before /usr/bin (it is not suggested to put
/usr/irix4/usr/bin in the PATH), then a slightly misleading error message will
be displayed.

Incorrect usage of IRIX4 compatibility mode:
% /usr/irix4/usr/bin/cc hello.c
cc: Error: ANSI C is not installed. (could not find /usr/lib/accom)

The same notions apply to FORTRAN and f77 (requires ftn *and* irix4_ftn;
setenv SGI_IRIX4 1; and use the /usr/bin/f77 driver).


* Installing system header files that are not a part of dev

To use the system header files (eg, /usr/irix4/usr/include/sys/types.h),
the irix4_eoe1.sw.unix subsystem needs to be installed (located on the
IRIX5 CD).  When compiling code in IRIX4 mode that #includes these system
files, the compiler won't be able to find the headers if irix4_eoe1.sw.unix
is not installed and errors will arise.  Trying to mix modes in using the
IRIX5 /usr/include/sys headers (by possibly putting "-I/usr/include" on
the compile line in IRIX4 mode) is the wrong thing to do and will cause
something like this error message:

accom: Error: /usr/include/sgidefs.h, line 113: Incomplete external data
declaration (missing storage class) or function definition missing () before
{function body}
       ERROR -- the macro "_MIPS_SZINT" is unset (currently, must be set to 32)
       -------^
accom: Error: /usr/include/sgidefs.h, line 113: syntax error
       ERROR -- the macro "_MIPS_SZINT" is unset (currently, must be set to 32)
       -------^
^L
* What OS release will we stop shipping IRIX4 products?

The IRIX4 products are shipped to help customers during the transition
to IRIX 5.1.  It is yet to be determined in which future release the IRIX4
compatibility mode will be yanked.  5.2?  6.0?


* What is not supported in IRIX4 compatibility mode?

The IRIX4 environment is strictly a "link and run" environment.  It was not
designed to extend into capabilities for debugging and performance tuning.
Therefore, only the compiler front ends (ie, cc and f77, but not yacc, prof,
pixie, and lint) were modified to recognize the SGI_IRIX4 environment variable.
Additionally, it is not guaranteed that the COFF executables that are
created with the IRIX4 compatibility mode will work on other systems whether
they have IRIX4 installed or not.  The IRIX4 compatibility mode is intended
to get the needed application to run on that IRIX5 system.


* What are the versions of products, including IRIX4 products, for IRIX5?

     Is in 5.0.1 Release                      Is in 5.1 Release
-------------------------------         -------------------------------
Media Label     Versions output         Media Label     Versions output
-----------     ---------------         -------------   ---------------
On 5.0.1 IDO:                           On 5.1 IDO:
  5.0.1 dev     5.0.1  dev                 5.1   dev    5.1    dev
  irix4_dev     3.10.1 irix4_dev           irix4_dev    3.10.1 irix4_dev
  3.16  c       3.16   c                   3.17  c      3.17   c
  irix4_c       3.10.1 irix4_c             irix4_c      3.10.1 irix4_c
3.1.1 C++       3.1.1 c++               3.2 C++         3.2   c++
  irix4_c++     3.0.1 irix4_c++            irix4_c++    3.0.1 irix4_c++
3.6.1 FORTRAN   3.16  ftn               4.0 FORTRAN     4.0   ftn
  irix4_ftn     3.5.1 irix4_ftn            irix4_ftn    3.5.1 irix4_ftn
1.4.1 Pascal    3.16  pas               1.4.2 Pascal    1.4.2 pas
  irix4_pas     1.3.1 irix4_pas            irix4_pas    1.3.1 irix4_pas
2.3 Power C     2.3   pwrc              2.4 Power C     2.4   pwrc
  irix4_pwrc    2.1.1 irix4_pwrc           irix4_pwrc   2.1.1 irix4_pwrc
3.3 ^ Fortran   3.3   pfa               4.0 ^ Fortran   4.0   pfa
  irix4_pfa     3.1.1 irix4_pfa            irix4_pfa    3.1.1 irix4_pfa



------------------------------------------------------
Known Bugs:
------------------------------------------------------

* irix4_ftn

Bug #159709:
Using IRIX4 compatibility mode on MR-ed IRIX 5.0.1, the compiler driver
attempts to link in -lftn instead of -lF77 -lU77 -lI77 -lisam.  The result
is that when using "setenv SGI_IRIX4 1; /usr/bin/f77 file.f", FORTRAN code
will not link.  The workaround is to invoke ld manually with the correct
libraries.  This bug applies only to 5.0.1 since the fix is in 5.1.
^L
-----------------------------------------
* irix4_c++

Bug #168556:
Background information-
3.0.1 c++ produces COFF object format.  3.0.1 c++ is compatible with
4.1.1 dev on IRIX 4.0.5.  There is an irix4_c++ product that comes with
3.1.1 c++ for IRIX 5.0.1.  That version of irix4_c++ is the 3.0.1 version.
ELF and COFF objects cannot be mixed.  To use all ELF, ie the 3.1.1 c++,
"/usr/bin/CC file.c".  To use all COFF, ie the 3.0.1 irix4_c++, this is
suppose to work: "setenv SGI_IRIX4 1; /usr/bin/CC file.c".

Problem-
When using IRIX4 compatibility mode on IRIX 5.0.1, the CC driver tries to
link in an ELF object with the newly compiled COFF objects.  If the IRIX4
compatibility mode is really needed, then workaround the problem by
issuing the setenv SGI_IRIX4 command, compile using -c, and then link by
using the IRIX4 driver:
   setenv SGI_IRIX4 1; CC -c try.c; /usr/irix4/usr/bin/CC try.o

There is no problem with the driver if producing ELF, just recompile
all sources and libraries with /usr/bin/CC (don't setenv SGI_IRIX4).
This is fixed in IRIX 5.1.

-----------------------------------------
* irix4_c

Bug #168471:
When cc is used with the -E option and SGI_IRIX4 env var, then the driver
tries to invoke /usr/irix4/usr/lib/cfe instead of /usr/irix4/usr/lib/acpp.

With IRIX 5.0.1 and the 3.16 c compiler:
% setenv SGI_IRIX4 1
% cc -E -v try.c
/usr/irix4/usr/lib/cfe -D__EXTENSIONS__ -DLANGUAGE_C -D_LANGUAGE_C
-D__INLINE_INTRINSICS -Dsgi -DSVR3 -D__SVR3 -D__sgi -Dunix -Dmips -Dhost_mips
-D__unix -D__host_mips -D__DSO__ -DSYSTYPE_SYSV -D_SYSTYPE_SYSV -D_LONGLONG
-D__mips=1 -I -D_MIPSEB -DMIPSEB -I/usr/irix4/usr/include try.c -E
-D_LANGUAGE_C-D_CFE -D__unix -D__host_mips -D__DSO__ -std
cc: Error: can't find or exec: /usr/irix4/usr/lib/cfe
  : No such file or directory

A workaround for IRIX 5.0.1 and the 3.16 compiler is to use the
/usr/irix4/usr/bin/cc driver instead of /usr/bin/cc and SGI_IRIX4 when
using the -E option.  In doing so the driver invokes /usr/lib/acpp instead
of /usr/irix4/usr/lib/acpp, but that does not appear to be a problem.
This is fixed in IRIX 5.1.
^L
-----------------------------------------
* irix4_gl_x_dev

Bug #163598:
Installing irix4_gl_x_dev on an IP19 (Challenge, Onyx) or IP22 (Indigo2)
or IP?? (Indy) does not install /usr/irix4/usr/lib/libgl_s.a or libgl.a
for the irix4_gl_x_dev that comes with 5.0.1 IDO.

Typically when this happens it is because the maint cd was not applied as a
final step.  In the case of IRIX 5.0.1 there is no maint cd and no
maint_irix4_gl_x_dev product.

The libgl_s.a and libgl.a libraries are the same for Crimson (IP17) with
RealityEngine graphics as on Onyx or Challenge with RealityEngine graphics,
so the following commands will install the missing files as a workaround.
This bug is fixed in the irix4_gl_x_dev of 5.1 IDO for IRIX 5.1.

% /bin/su
# mkdir /irix4_gl
# inst -r /irix4_gl -m CPUBOARD=IP17 -m GFXBOARD=VENICE -m SUBGR=IP17
-f /CDROM/dist/irix4_gl_x_dev
# cp /irix4_gl/usr/lib/libgl* /usr/irix4/usr/lib
# versions -r /irix4_gl remove irix4_gl_x_dev
# rm -rf /irix4_gl

-----------------------------------------
* irix4_pca

Bug #168939:
When using the -pca option to cc in IRIX4 compatibility mode on IRIX
5.0.1, the cc driver omits the libmpc.a (-lmpc) library on the link line.
This is fixed in IRIX 5.1.

% setenv SGI_IRIX4 1
% cc -pca -v try.c
...
/usr/irix4/usr/bin/ld -L -L/usr/irix4/usr/lib/ -G 8 -g0 -nocount
/usr/irix4/usr/lib/crt1.o -count try.o -nocount -lc_mp -lkapio -lc
/usr/irix4/usr/lib/crtn.o
ld:
Error: Undefined:
usconfig
usinit
_lfopen
_lfwrite
_lfread
_lfseek
_lfclose

The workaround is to explicity link in -lmpc.  For example:
% setenv SGI_IRIX4 1
% cc -pca try.c -lmpc
%
^L
-----------------------------------------
* irix4_pfa

Bug #168941:
When using the -pfa option to f77 in IRIX4 compatibility mode on IRIX
5.0.1, the f77 driver passes to the pfa stage illegal options (options
suitable for the IRIX 5.0.1 version of pfa).

% setenv SGI_IRIX4 1
% f77 -pfa -v try.f
...
/usr/irix4/usr/lib/pfa -L=/usr/tmp/ctmka001BUl1 -F=/usr/tmp/ctmka001BUm1
-I=/usr/tmp/ctmpa001BU -lo=lno -noanalysis -original_filename=try.f
-include=/usr/include -cp=i
 Command line error -- unrecognizable string: "noanalysis"
 PFA -- Command Line Syntax Error Detected

The problem is that the IRIX4 version of pfa does not understand either
of -noanalysis or -original_filename options.  The IRIX4 version of
the -original_filename flag is -customer.  The workaround is to invoke
pfa manually with the correct options.  This is fixed in IRIX 5.1.

-----------------------------------------
* ada 6.2.1 (on 5.0.x == IRIX4 mode)

Bug #159228:
Background info:
AXM 6.2.1 (Ada with X and Motif bindings) installed on 5.0.1 machines
generates COFF objects and therefore tries to link in libraries under
/usr/irix4/usr/lib.

The problem:
The install script, which gets executed as an exit operation to the inst
process, sets the wrong path for the X libraries.  As a result, the ada
pre-linker attempts to find the libraries in /usr/lib (the incompatible
ELF object file format versions) instead of /usr/irix4/usr/lib.

The Workaround:
/bin/su
cd /usr/vads
vi sup/a.install.axi.sgi
   change line 49 to
      XLIB_LOCATION="/usr/irix4/usr/lib"
   from
      XLIB_LOCATION="/usr/lib"
sup/a.install.sgi .

This is fixed in AXM 6.2.3 and higher.
^L
------------------------------------------------------
More IRIX4 tidbits
------------------------------------------------------

A few more notes about using the IRIX4 compatibility build environment:

   o If there are undefined symbols, and the linking worked
     on 4.0.x, add -nostdlib -L/usr/irix4/usr/lib or
     -nostdlib -L/usr/irix4/usr/lib -L/usr/irix4/usr/lib/mips2
     to the cc or f77 command line.

   o If the compilation is -mp, add -lI77_mp -lmpc at the end of
     the command line to avoid multiply defined warnings from ld.

   o If you are linking Fortran objects and the -lX11 or -lX11_s
     library, then link in -lmpc before -lgl or -lgl_s to avoid
     warnings about multiply defined symbols between libmpc.a and
     libX11.a (or libX11_s.a).

   o The -v2 switch is removed in the 3.1 c++ compiler that is
     shipped with IRIX 5.0.  The effect of this is that those
     applications that do not compile under c++ 3.x will not have
     the ability to use 2.x C++ compatibility mode.  The -v2 switch
     option is not available in IRIX4 compatibility mode either
     since it is the 3.x driver that is invoked which no longer
     recognizes -v2.

------------------------------------------------------
See Also:
------------------------------------------------------
5.0.1 or 5.1 IRIX relnotes if installed ("grelnotes IRIX")



There is one area that Dave Frederick didn't mention explicitly, but
is implicit in every new release: undocumented "features" aren't
guarenteed to remain. The trouble is, these are so arbitrary that
you generally don't find them until your code breaks.

The only such case I know of is fsync. In Irix 4 and several other
vendor's products, fsync also syncs directories, although this isn't
obvious from the documentation. This stopped working in Irix 5.0.

Why do you sync a directory? To make sure that file attributes are
synced along with file contents in a database. Simply fsyncing a file
would not necessarily update its attributes.






# 3.  Is it reasonable to expect that if __STDC__ is
      defined to be long double it will be supported?
------------------------------------------------------------
Newsgroups: sgi.engr.devp
Subject: Re: Long doubles and __STDC__
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 23 Sep 1993 04:26:36 GMT

>A developer is curious about support for long doubles.  They are
>expecting that if __STDC__ is defined that the compiler
>should support long double.  Since they are compiling -xansi __STDC__ is
>defined and they get warnings when they try use long double.
>
>I look in float.h and it has comment which reads:
>
>/*
> * Note: For now, all constants that refer to long doubles (LDBL) are
> * filled in with values for DBL.
> */
>
>This is on 5.1 MR.  Bottom line is, I think, the compilers convert long
>double to double with a warning.   Is it reasonable for the developer
>to expect that if __STDC__ is defined that long double will be supported?

The problem here is the developer does not understand the ANSI Standard.

(I don't have the Std here at home. I'm taking 'long double' as
actually being in the C std on faith.)

By turning 'long double' into 'plain double' and compiling and running
as such,
    This is what the C standard requires.

Nowhere in the standard is IEEE arithmetic nor a 64-bit long double
mandated.

There is only one sense in which long double must be different from
double:
    double *x
    long double *y
must not be treated the same even though we represent thm
the same in released compilers.

>>     That's not a problem, I'm using doubles on the Sun.  But it does
>> raise an interesting question: why is SGI defining __STDC__ if it is
>> *not* supporting long doubles?  Here is the relevant code:
>>
>> #ifdef __STDC__

Again: there is no lack of conformance here.  There is
a user misunderstanding of a particular point.

If this is not enough I can quote the standard sections tomorrow...
Or H&S or K&R if that is what the developer has to look at...






# 4.  'mkshlib' command:  trying to create a shared library
------------------------------------------------------------
Newsgroups: comp.sys.sgi.apps
From: [e-mail] (David B.Anderson)
Subject: Re: mkshlib
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 23 Sep 1993 03:34:58 GMT

In article <27psug$[e-mail]> [e-mail] (Michael Morrison) writes:
>Does anyone have any further info on the 'mkshlib' command?  I am trying
>to create a shared library, and having numerous difficulties.
>
>Specifically, what are the REAL command options?  E.g: '#objects noload'
>is not documented in the man-page.  The errors produced are difficult
>to understand, such as:
[some stuff deleted]

  '#objects noload' is not documented since it's not supported.

>This is under 4.0.5F, as well as older versions.

>Sorry if this is documented somewhere and I just can't find it.

Well, producing static shared libraries is very difficult.

The end result of the difficult process of creating one is
a library type which is obsolete as of SVR4 and IRIX5.
Any existing libraries continue to *work* I hasten to add.
But they are replaced by dynamic shared objects, and
dynamic shared objects (dso-s) are easy to build and use.

Of course I cannot promise when IRIX5 will be available to you.
But I'd suggest you simply use plain archive files till it is.

SUMMARY: give up in static shared libraries, please!
(If you really MUST have them (like your thesis depends on it :-) send
me email.)

BTW: if your library source  is in C, a static shared library is
possible. IF it is Ada, C++, or Fortran you had better give up now
:-)   (Well we managed (sort of) with C++ but the result is not easy to
live with.)






# 5.  where did logname() go in 5.1 Irix?
------------------------------------------------------------
Newsgroups: sgi.engr.devp
Subject: Re: what happened to logname() ?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 23 Sep 1993 17:41:21 GMT

> >  Likely sccs was the only SGI product using the library [libPW]
>
> In Irix 4, libPW contained regex() and regcmp().  These commonly
> used functions have apparently migrated to some other library in Irix 5.
>
These appear to have landed in libadm.a on IRIX 5.1.






# 6.  why does fflush call itself so often?
------------------------------------------------------------
Newsgroups: sgi.engr.all
Subject: Re: Why does fflush call itself so often
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 24 Sep 1993 10:11:18 GMT

|> |> And here is a list of functions along with the number of times they were called.
|> |>        101    fflush
|> |>         98    _lseek
|> |>
|> |> 100 of the calls to fflush were recursive. One was from _cleanup.
|>
|> Because _cleanup calls fflush(0), which as the man page documents:
|>
|>      fflush causes any unwritten buffered data for the named stream to be
|>      written to that file.  The stream remains open.  If the value of stream
|>      is NULL, all streams associated with the process are flushed.
|>
|> Then fflush(0) simply calls itself with a non-NULL arg for each
|> stdio stream that might exist.
|>
|> The real question to my mind is why did all the fflush calls
|> cause an _lseek, which is a real system call, and would seem
|> unnecessary to me, on file descriptors that stdio has never
|> worked with in that process.

The stupid lseeks and extra fflushs was fixed late in 5.1






# 7.  when will I see 64 bits?
------------------------------------------------------------
From: [e-mail] (Steve Whitney)
Newsgroups: comp.sys.sgi.misc
Subject: Re: when will I see 64 bits
Date: 23 Sep 1993 23:19:03 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 19

In article <[e-mail]>,
Henry Cejtin <[e-mail]> wrote:
>It's been a long time now since MIPS started shipping the R4000, but even  on
>IRIX  5.0.1  there seems to be no 64 bit support.  When will the OS allow one
>to run user processes in 64-bit mode, and when will the compiler  generate
>such code?

The version of Irix to be released on the POWER Challenge platform will i
support 64-bit user processes.  It will also ship with compilers capable
of generating this code.

POWER Challenge is currently scheduled to ship with the TFP processor
some time in early 1994, though, as always, you should check with your
sales rep for official dates.  (I'm just an engineer!)






# 8.  will SGI's C++ compiler include exception handling?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.apps
From: [e-mail] (Anil Pal)
Subject: Re: REQUEST TO SGI C++ COMPILER DEVELOPERS
Organization: Silicon Graphics, Inc.
Date: Thu, 30 Sep 1993 00:27:32 GMT
Lines: 22

In article <[e-mail]>, [e-mail] (Mitch Voehl) writes:
|> REQUEST TO SGI C++ COMPILER DEVELOPERS
|>
|> I'm involved in porting an existing software package which contains
|> exceptions, and require a compiler which implements them.  I've been
|> told that the C++ compiler which SGI is writing will not include
|> exceptions.

The first release of the compiler will not include exception handling
(it will be source-code compatible with the langauge as of cfront
3.x).  Exception handling is definitely planned for a subsequent
release of the compiler.

|> When will SGI have a C++ compiler which implements exceptions?  I
|> need them now.

It's a bit early to talk about dates for future releases.






# 9.  when were the C preprocessor symbols "sgi" & "_sgi" introduced?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (David B.Anderson)
Subject: Re: sgi vs. __sgi history
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 27 Sep 1993 23:47:02 GMT

In article <andras.749160057@concave> [e-mail] (Andras Salamon) writes:
>
>Does anybody know when the C compiler preprocessor symbols sgi and
>__sgi were introduced?  Knowing which symbols are unique to which
>version of IRIX would make it easier to contribute patches when porting
>software to run on IRIX.

__sgi was introduced with ANSI C: sgi is a *user* symbol in strict
ANSI mode.    __sgi only tells you that this is not an
IRIX 3.3.? compiler release.

Even if you use
    file
on some binary the compiler version number *at best* works for
irix4.  So far, IRIX5 binaries report only a 'version 1' (elf version,
not compiler version) which is not what you are after.

But
    file
is probably your best bet:
actual output:
    file /usr/lib/accom
/usr/lib/accom: mipseb demand paged stripped (R4000 fpdiv
   unchecked) - version 3.12
                ^^^^^^^^^^^^
IRIX4.0.1                    version 2.10
IRIX4.0.5 base compilers     version 2.40
IRIX4.0.5 3.10 compilers     version 2.40
IRIX4.0.5 3.10.1  compilers  version 3.12

IRIX5   (any)
davea-166: file /usr/lib/cfe
/usr/lib/cfe:   ELF 32-bit MSB dynamic executable MIPS - version 1

Maybe someone else will have a  better idea.






#10.  getting "undefined" errors again with C++ linking
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (Anil Pal)
Subject: Re: HELP: C++ linking again
Organization: Silicon Graphics, Inc.
Date: Tue, 28 Sep 1993 01:04:57 GMT
Lines: 34

In article <27q7u0$[e-mail]>, [e-mail] (Donn Mielcarek) writes:
|>
|> This is driving me crazy. What do I need to link? Here's the code:
|>
|> #include <iostream.h>
|>
|> main()
|> {
|>     cout << 'A' << endl;
|> }
|>
|> compiled with:
|>     CC file.C -o file -lC -lc_s
|>
|> compiler says:
|>
|> /usr/bin/ld:
|> Undefined:
|> ostream::ls_complicated(char)

If this isn't in the FAQ by now, it should be.  The C++ library,
libC.a, is part of the development option (IDO), since it is needed by
some development libraries.  if you install a new version of C++ (e.g.
C++ 3.0) without installing the required version of the IRIS
Development Option (4.1, I believe), you will see problems like this.

Check the release notes for your version of C++ and see which version
of the devlopment option it requires.

(which provides a new libC.a)






#11.  FORTRAN Intrinsic Function Generic Name. Is the Manual Wrong?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.misc
From: [e-mail] (David A. Frederick)
Subject: Re: FORTRAN Intrinsic Function Generic Name. Is the Manual Wrong?
Organization: Silicon Graphics, Inc.
Date: Wed, 29 Sep 1993 08:12:09 GMT
Lines: 110

In article <[e-mail]>, [e-mail] (John H. Chauvin) writes:
|>
|> I'm confused. According to the Fortran 77 Language
|> Reference Manual, page A-5, the generic name for the
|> intrinsics function  AMAX1 is MAX1. Is this right? Most
|> books on Fortran 77 show MAX1 as a stand alone function
|> which equates to  INT(MAX(r1,r2,...)). This same argument
|> applies to the MIN1 function.  My understanding is that
|> MAX should be the generic name  for MAX0, AMAX1, and
|> DMAX1. MIN should be the generic name for MIN0, AMIN1,
|> and DMIN1. Both MAX1 and MIN1 have no generic name.
|>
|> Is the manual wrong? Am I wrong? What are the
|> generic names for:
|>
|>           AMAX1?
|>           AMIN1?
|>
|> John Chauvin
|> Northrop Advanced Technology and Design Center
|> Pico Rivera, California
|> Email:[e-mail]

Well you appear to be partially correct.  The ANSI standard's table
(page 15-23) is different from the F77 LRM's table (and MAX(3F) manual
page) in that it is as you said.  It isn't clear that MAX1 and MIN1
have no generic name since Section 15 of Appendi x B says the following:

   For the specific functions that define the maximum and minimum values
   with a function type different from the argument type (AMAX0, MAX1,
   AMIN0, MIN1), it is recommeneded that an expression containing the
   generic name preceded by a type conversion function be used, for
   example, REAL(MAX(a1, a2, ...)) for AMAX0(a1, a2,...), so that these
   specific function names may be deleted in a future revision of this
   standard.

This implies to me that MAX is the generic name for AMAX0.  At any rate,
it appears that it is just the manual and manual page that is incorrect
and not the software.  Enclosed is a sample program and dis -S -h output
for the relevant parts.

C File:     intr.f
c Compile:  f77 -O0 intr.f
c
        intrinsic max1, max, amax1
        real j,m,n
        j=1.0
        m=2.0
        n = max(j,m)
        type *, 'n is ', n

        n = max1(j,m)
        type *, 'n is ', n

        n = amax1(j,m)
        type *, 'n is ', n

        stop
        end


% dis -h -S a.out | more
5:      n = max(j,m)
  [intrinsic2.f:   5] 0x4002c8: c7a8003c        lwc1    $f8,60(sp)
  [intrinsic2.f:   5] 0x4002cc: c7aa0038        lwc1    $f10,56(sp)
  [intrinsic2.f:   5] 0x4002d0: 00000000        nop
  [intrinsic2.f:   5] 0x4002d4: 460a403c        c.lt.s  $f8,$f10
  [intrinsic2.f:   5] 0x4002d8: 00000000        nop
  [intrinsic2.f:   5] 0x4002dc: 45000002        bc1f    0x4002e8
  [intrinsic2.f:   5] 0x4002e0: 00000000        nop
  [intrinsic2.f:   5] 0x4002e4: 46005206        mov.s   $f8,$f10
  [intrinsic2.f:   5] 0x4002e8: e7a80034        swc1    $f8,52(sp)

8:      n = max1(j,m)
  [intrinsic2.f:   8] 0x400334: c7b0003c        lwc1    $f16,60(sp)
  [intrinsic2.f:   8] 0x400338: c7b20038        lwc1    $f18,56(sp)
  [intrinsic2.f:   8] 0x40033c: 00000000        nop
  [intrinsic2.f:   8] 0x400340: 4612803c        c.lt.s  $f16,$f18
  [intrinsic2.f:   8] 0x400344: 00000000        nop
  [intrinsic2.f:   8] 0x400348: 45000002        bc1f    0x400354
  [intrinsic2.f:   8] 0x40034c: 00000000        nop
  [intrinsic2.f:   8] 0x400350: 46009406        mov.s   $f16,$f18
  [intrinsic2.f:   8] 0x400354: 444ef800        cfc1    r14,$31
  [intrinsic2.f:   8] 0x400358: 00000000        nop
  [intrinsic2.f:   8] 0x40035c: 35c10003        ori     r1,r14,0x3
  [intrinsic2.f:   8] 0x400360: 38210002        xori    r1,r1,0x2
  [intrinsic2.f:   8] 0x400364: 44c1f800        ctc1    r1,$31
  [intrinsic2.f:   8] 0x400368: 00000000        nop
  [intrinsic2.f:   8] 0x40036c: 46008124        cvt.w.s $f4,$f16
  [intrinsic2.f:   8] 0x400370: 44cef800        ctc1    r14,$31
  [intrinsic2.f:   8] 0x400374: 440f2000        mfc1    r15,$f4
  [intrinsic2.f:   8] 0x400378: 00000000        nop
  [intrinsic2.f:   8] 0x40037c: 448f3000        mtc1    r15,$f6
  [intrinsic2.f:   8] 0x400380: 00000000        nop
  [intrinsic2.f:   8] 0x400384: 468032a0        cvt.s.w $f10,$f6
  [intrinsic2.f:   8] 0x400388: e7aa0034        swc1    $f10,52(sp)

11:     n = amax1(j,m)
  [intrinsic2.f:  11] 0x4003d4: c7a8003c        lwc1    $f8,60(sp)
  [intrinsic2.f:  11] 0x4003d8: c7b20038        lwc1    $f18,56(sp)
  [intrinsic2.f:  11] 0x4003dc: 00000000        nop
  [intrinsic2.f:  11] 0x4003e0: 4612403c        c.lt.s  $f8,$f18
  [intrinsic2.f:  11] 0x4003e4: 00000000        nop
  [intrinsic2.f:  11] 0x4003e8: 45000002        bc1f    0x4003f4
  [intrinsic2.f:  11] 0x4003ec: 00000000        nop
  [intrinsic2.f:  11] 0x4003f0: 46009206        mov.s   $f8,$f18
  [intrinsic2.f:  11] 0x4003f4: e7a80034        swc1    $f8,52(sp)


The LRM's table says that MAX1 is the generic name for AMAX1, whereas the ANSI standard says that MAX is the generic name for AMAX1.  The above output seems to show that the compiler abides the standard.

I will file a documentation bug unless I missed something.






#12.  Can one do Parallel processing without Power C?
------------------------------------------------------------
Newsgroups: comp.sys.sgi
From: [e-mail] (Gavin Bell)
Subject: Re: Parallel processing without Power C?
Date: 28 Sep 1993 05:44:56 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 22

Timothy Cullip <[e-mail]> wrote:
>If a person doesn't want to buy (or can't afford) Power C, are there any
>options for using multiple processors within a single program on a
>multiprocessor SGI (like our four processor Onyx)?
>
>I could do (and we have done) some work using multiple processes that
>explicitly use shared memory, semaphores, and/or sockets, but it's clumsy.

I've used both raw sproc() and the m_fork() routines that come
standard with IRIX with great success in the past.  I agree that the
SYSV-style semaphores and shared memory are a royal pain-- I'd suggest
you stay away from them and use the IRIX-specific stuff; see the
usinit() and usnewsema() man pages, which aren't too hard to use.
Also try the m_fork() and sproc() man pages (you'll probably use the
PR_SALL argument to sproc to share memory and everything else between
threads).

I haven't been impressed with Power C, but the applications I was
parallelizing were much better suited to a higher-grained parallelism.






#13.  What the IRIX 64bit implementation be of
      variable declarations for c and c++ ?
------------------------------------------------------------
Newsgroups: sgi.engr.devp
From: [e-mail] (David B.Anderson)
Subject: Re: IRIX 64bit question from Developer
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 1 Oct 1993 21:13:32 GMT

>>> Subject: IRIX 64bit question from Developer
>>>
>>> developers are enthusiastically
>>> awaiting their opportunity to port to 64bit
>>> IRIX (they completed the painful DEC-alpha
>>> port) and had a question I could not
>>> answer.
>>>
>>> What is will be the IRIX 64bit implementation
>>> of variable declaration for c and c++ ? Is
>>> there any sort of summary or short report
>>> on this that I could access?

In the sgi 64-bit model (applies to 64-bit programs, not
to 32-bit programs even if the 32-bit program is running on
64-bit-capable OS):

  8-bit:   char, unsigned char, signed char

  16-bit:  [signed] short, unsigned short

  32-bit:  [signed] int, unsigned int
       float

  64-bit:  [signed] long, unsigned long
       all pointers
       double

  128-bit: long double

malloc space aligned to 16-byte boundaries (ie multiple of 16, for
long double).  Stack alignment of the stack pointer required to
be 16-byte boundary.






#14.  variable length arglist problem
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (Paul Jackson)
Subject: Re: variable length arglist problem
Date: 1 Oct 1993 04:44:21 GMT
Organization: Silicon Graphics, Research & Development
Lines: 23

In article <28fes2$[e-mail]>, [e-mail] (Steven L. Smith) writes:
|> Why is the routine findmaxf not working properly in the code below?
|> #include <stdarg.h>
|>
|> float findmaxf(float n1,...)
|> {
|>   va_list  argp;        /* Argument pointer. */
|>
|>   va_start(argp,n1);

To quote the stdarg man page:

     void va_start (va_list ap, ParmN);

     The ANSI C Standard (ANSI X3.159-1989) restricts the type of parmN to one
     of the types resulting from the default argument promotions, currently
     int, unsigned int, pointer, or double.






#15.  SGI's policy re:  the Delta C++ compiler?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (Anil Pal)
Subject: Re: SGI's C++ Policy
Organization: Silicon Graphics, Inc.
Date: Sat, 2 Oct 1993 00:27:23 GMT
Lines: 40

In article <[e-mail]>, [e-mail] (T.F. Wiegand) writes:
|> Can anyone from SGI comment on their policy with regards to C++ ?
|>
|> Is this new "native" compiler intended to replace SGI's current cfront based
|> C++ offering? If I bought WorkShop Pro C++ would I need the standard C++
|> product and WorkShop as well ? Will development of the cfront based product
|> continue or is this a cynical ploy to make existing C++ users pay again to
|> get continued language updates :-).

OK, I'll try to provide some more info.  This is *not* the final word,
and not the official position, but just my understanding of the current
state of affairs:

1. The initial release of WorkShop Pro C++ will initially be the only
   way to get your hands on the Delta/C++ compiler.

2. The Delta/C++ compiler will eventually be broken out and delivered
   stand alone, without the smart build facility.

3. This compiler will be made available on a future release of IRIX.

4. The cfront-based translator will continue to be available for some time.
   Current guess is at least one year, maybe more.

5. During the overlap period, C++ libraries will be delivered in both cfront
   and Delta form.

6. Note that the new compiler can be used in non-Delta mode, and will generate
   cfront-compatible .o's

7. SGI effort for new feature additions (e.g. exceptions) will be
   directed at the new compiler, for obvious reasons.

8. Upgrade policy for existing cfront customers beyond the lifetime of the
   old translator hasn't been finalised, but I would guess we will be
   reasonable on this one.






#16.  Usinit et al. disturbs real-time-ness
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (Chris Wagner)
Subject: Re: Usinit et al. disturbs real-time-ness
Date: 4 Oct 1993 17:57:36 GMT
Organization: Silicon Graphics, Research & Development
Lines: 48

In article <[e-mail]>, [e-mail] (Peter Mutsaers) writes:
|>
|> we use some real-time processes, with non-degrading priorities
|> and locked memory. However, when disk activity occurs the process
|> may get delays as high as 20 milliseconds, which is fatal to the
|> application.
|>
|> This only happens when usinit etc. (shared arenas) are used.
|>
|> SGI in the Netherlands has not been able to help us yet.
|>
|> Could this be a bug in the shared arenas? Or is it normal, since mmap()
|> underlies them. My theory was that mmap() mirrors the new (locked)
|> address space provided by it also in the filesystem buffer.
|> Now, when another process fills the filesystem buffer, such updates may
|> not fit anymore in physical memory and the real-time process much wait
|> for disk access to complete. Could this be a cause?

usinit arenas by default us AUTOGROW mapped files - when you call usmalloc
(or some other us* call that must malloc memory) and the arena needs to grow
if the underlying file isn't large enough it will be grown automatically -
this of course causes disk activity.

If you are not mallocing, and not paging, then there shouldn't be
any reason for the dirty mmaped pages to be returned to disk. By
default, unless you call msync or close the mapped file, pages of
mapped file you write through your address space are not put
in the 'buffer; cache.

As a first test - after calling usinit, make sure the file is a large size

I assume you are running on 4.X?? not 5.X - under 5.X you can specify
that the arena file not be autogrow - at usinig time it will be
grown to the size you request.






#17.  how do i call a C++ member function from within dbx?
------------------------------------------------------------
Newsgroups: comp.sys.sgi
From: [e-mail] (David B.Anderson)
Subject: Re: dbx & c++
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 7 Oct 1993 18:29:56 GMT

In article <CEHH6K.LtA@da_vinci.it.uswc.uswest.com> [e-mail] (Robert Dorgan) writes:

>One thing I havent been able to figure out is how to call a
>member function from within dbx. ccall doesnt seem to handle
>stuff like "ccall this->func()".

Describing both IRIX4 and IRIX5:

    ccall  class::func(this)

might work better.  Note you have to supply the implicit argument
yourself (that's why it's called ccall: it is not language sensitive
and pretends all called functions are C).  And you must know the right
class (there is no attempt to access a virtual function table in
finding the function address).

print   class::func(this)
works the same (same restrictions)

And because there is no specifying WHICH of a group of overloaded
functions is to be called, you will wind up getting them ALL called in
some order.  But for some the arguments are surely wrong.
And if they have different numbers of arguments or the arguments
fail a type-matching operation ,dbx will object and
stop dealing with the command.

In other words, c++ interactive calls work for simple cases.  But not
as nicely as you might wish.






#18.  Why does ld add -lX11_s when it sees -lgl_s ?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.graphics
From: [e-mail] (David B.Anderson)
Subject: Re: Why does ld add -lX11_s when it sees -lgl_s ???
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 12 Oct 1993 20:34:15 GMT

In article <[e-mail]> [e-mail] (Kent Williams) writes:
>I built the X11R5 libraries under SGI Irix 4.0.5 .  Then I compiled my
>application with them, and linked with libgl_s.a.  But cc insists on
>linking libX11_s.a even if I don't specify it.  If you type
>
>cc -v junk.o -lgl_s
>
>The output is
>
>/usr/bin/ld -G 8 -g0 -nocount /usr/lib/crt1.o -count junk.o -lgl_s -lX11_s \
>                                      what the hell is this? -------^^^^^^
>-nocount -lc_s -lc /usr/lib/crtn.o
>
>I have to use the shared gl library if I want to support more than one
>kind of Iris graphics hardware.
>
>This causes icky problems if you want to use R5 libraries since ld will report
>lots and lots of multiply defined symbols between X11.a and X11_s.a. I don't
>know if the program still works.

gl_s REQUIRES libX11_s to work.  If you  (or the compiler) don't put
-lX11_s on the ld line, x11_s is *still* used at run time thru some
kernel magic.

It was the magic factor that lead us to have the -lgl_s cause -lX11_s
to be added by the cc/f77/pc driver.  (I changed the cc/f77/pc driver
to do this before 4.0.1 was released.) The result is that X11_s shows
up in odump -L output and it makes the use of X11_s not seem like
magic.  In addition, -lc_s is added automatically when you use -lgl_s.
Similar reasons.

If you link with
    /usr/lib/libgl_s.a
rather than
    -lgl_s
on the command line
you will not see -lX11_s on the command line and the linker won't
object.  And odump -L won't show libX11_s.

If you link this way with your own X11R5 I have no idea whether the
result will work or which X11 you will actually be using at run time.


Newsgroups: comp.sys.sgi.graphics
From: [e-mail] (Dave Olson)
Subject: Re: Why does ld add -lX11_s when it sees -lgl_s ???
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 13 Oct 93 00:20:56 GMT
Lines: 12

In <[e-mail]> [e-mail] (David B.Anderson) writes:
| gl_s REQUIRES libX11_s to work.  If you  (or the compiler) don't put
| -lX11_s on the ld line, x11_s is *still* used at run time thru some
| kernel magic.

The latter was done to allow 3.3 binaries to run, since libX11_s didn't
exist in 3.3, by the way.



Newsgroups: comp.sys.sgi.graphics
From: [e-mail] (Mark Kilgard)
Subject: Re: Why does ld add -lX11_s when it sees -lgl_s ???
Date: 13 Oct 1993 02:45:53 GMT
Organization: Silicon Graphics, Inc.
Lines: 79

In article <[e-mail]>, [e-mail] (Kent Williams) writes:
|> I built the X11R5 libraries under SGI Irix 4.0.5 .  Then I compiled my
|> application with them, and linked with libgl_s.a.  But cc insists on
|> linking libX11_s.a even if I don't specify it.  If you type
|>
|> cc -v junk.o -lgl_s
|>
|> The output is
|>
|> /usr/bin/ld -G 8 -g0 -nocount /usr/lib/crt1.o -count junk.o -lgl_s -lX11_s \
|>                                       what the hell is this? -------^^^^^^

It is the X11R4 static shared Xlib library.  The IRIS GL automatically
links with it in IRIX 4.0.x.  Before 4.0.x, IRIS GL programs simply linked
with the IRIS GL library.  With the advent of using X as the native
window system, the IRIS GL interoperates with X behind the scenes.  To
avoid breaking Makefile's and so old programs would work, linking with
-lgl_s automatically pulls in the X11R4 Xlib static shared library.

|> -nocount -lc_s -lc /usr/lib/crtn.o
|>
|> I have to use the shared gl library if I want to support more than one
|> kind of Iris graphics hardware.

Yes.

|> This causes icky problems if you want to use R5 libraries since ld will report
|> lots and lots of multiply defined symbols between X11.a and X11_s.a. I don't
|> know if the program still works.
|>
|> Here are some of the error messages:
|>
|> Warning: _XFlush: multiply defined
|>         previous (used) definition from '/usr/local/X11R5/lib/libX11.a';
|>         new (ignored) definition from '/usr/lib/libX11_s.a'
|> Warning: _XIOError: multiply defined
|>         previous (used) definition from '/usr/local/X11R5/lib/libX11.a';
|>         new (ignored) definition from '/usr/lib/libX11_s.a'
|> Warning: _XEventsQueued: multiply defined
|>         previous (used) definition from '/usr/local/X11R5/lib/libX11.a';
|>         new (ignored) definition from '/usr/lib/libX11_s.a'
|>
|> etc, etc ...

Yes, what you are doing is not supported.  Mixing the IRIS GL library with
another version of Xlib is not supported.  You will definitely have problems
and it won't work.

|> But if I capture the ld command, and take out -lX11_s, then I get a bunch
|> of undefined externals like this:
|>
|> _libX_errno
|> _libX___XErrorFunction
|> _libX___XIOErrorFunction
|> _libX___Xdebug
|> _libX___XHeadOfDisplayList
|> _libX__qfree
|> _libX__ctype
|> _libX_sleep
|> _libX__filbuf
|> _libX__flsbuf
|> _libX__iob
|> _libX__semgetc
|> _libX__semputc
|> _libX__us_rsthread_stdio

Yes, this has to do with how the libX11_s static shared library is constructed.

If you want to use X11R5, I suggest you ask about upgrading to IRIX 5.1 or
later.  It includes X11R5.

If you program is a simply IRIS GL programming (no mixed-model programming
or X connections on the side), you should not need to link with an X11R5
library.  Perhaps you can explain why you want to link with X11R5 Xlib
 and IRIS GL.

The X11R5 library you built should work just fine for pure X clients.






#19.  lex question re: yywrap()
------------------------------------------------------------
Newsgroups: sgi.engr.devp
Subject: Re: lex question
Date: 13 Oct 1993 00:42:34 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 21

>There's a developer who's priority is having a clean ABI-compliant
>product.  They're linking with libl (lex) and apparently only using
>the function 'yywrap'.  Now that doesn't seem to make a whole lot of
>sense to me, since according to the lex man page, it's called at
>end-of-file, and "indicates whether normal wrapup should continue".

The version of yywrap() in libl really doesn't do a whole lot; in fact,
the entire definition is

    int yywrap() { return 1; }

If you don't want to link with libl, you can just include the above
definition yourself.

As for the intent, yywrap() allows you to hook the analyzer's actions when
it finishes processing a file; in this way, a user could potentially open
another file and continue tokenizing if desired.






#20.  R4000 and R4200 and instruction caching
------------------------------------------------------------
Newsgroups: sgi.engr.all
Subject: Re: R4000 and R4200 question
Date: 13 Oct 1993 15:50:01 GMT
Organization: Silicon Graphics, Inc.
Lines: 40

|> Lets say I have two instructions:
|>
|>     lw    t0,N(t1)
|>     lw    t2,M(t3)
|>     nop
|>
|> And lets say that the first instruction data fetch misses the primary
|> cache. Does the second instruction immediately, or does it wait until
|> the primary cache is filled? If it does execute, and M(t3) is in the
|> primary cache, will the nop execute before the first instruction
|> completes the primary cache fill, or after?

The r4400 and r4200 are both single issue machines with blocking
caches and they issue instructions in program order and retire instructions
in program order. So the second load will have to wait for the cache miss
caused by the first load to complete (the pipeline is stalled). No
instructions will complete until the cache miss caused by the first load
is finished.






#21.  is there a way to link COFF & ELF objects together under 5.1?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (Asgeir Eiriksson)
Subject: Re: coff/elf
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 7 Oct 93 23:07:06 GMT
Lines: 22

In <[e-mail]> [e-mail] (Jeff Michaud) writes:

>Is there some way to link COFF and ELF objects together under IRIX 5.1?
>Is there a way to convert between the two formats?  I looked and rtfm'd
>but couldn't come up with anything.

>From the IRIX release notes for 5.0 (/usr/sbin/grelnotes):

       ..... The IRIX 5.0 compilation tools do not support
       linking objects built in an IRIX 4 environment (COFF format)
       with objects built in an IRIX 5 environment (ELF).  It is
       not possible to link .o or .a files, unless they are all
       compiled with IRIX 5.0 tools or are all compiled with IRIX
       4.0.x or the IRIX 4 compatibility tools.



From: [e-mail] (Jay McCauley)
Subject: Re: coff/elf
Organization: Silicon Graphics, Inc.
Date: Fri, 8 Oct 1993 16:32:41 GMT
Lines: 42

Another post cites the Release Notes (thanks, Asgeir) which are correct,
this is not permitted.  Let me comment, briefly, on why, as it might
seem arbitrary on our part.

ELF vs ECOFF is more than just the format of the object modules in
IRIX 5.x.  We use the fact that something is in ELF form to trigger
the use of the SVR4 interfaces which include the use of Expanded
Fundemental Types (EFT).  EFT changes the size of a number of
system-defined types, and introduces new typedef's for others
while making the underlying thingy bigger.  For example the new
uid_t is a 32 bit quantity, bidding fond farewell to the
last vestages of the PDP-11 native integer size.  These type
changes also change the shape of "popular" structures.  An ECOFF
object would have embedded in its code assumptions about these
offsets which would be incorrect if an SVR4 style structure was
used.  If you are lucky the resulting program would crash, if you
are unlucky, it silently gets the wrong answers.

So, even if you monkeyed around with the object files with some new
tool transforming ECOFF into ELF, the result would almost undoubtedly
not work as you would want it to.

IRIX 5.x does include a collection of libraries and include files
that permit IRIX 4.x developed libraries and *.o files to be continue
to be used.




#22.  using "-D__STDC__=1":  struct sigcontext not included in compilation
------------------------------------------------------------
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.misc
From: [e-mail] (David B.Anderson)
Subject: Re: HELP!!  struct sigcontext not being included in compilation!!
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 9 Oct 1993 14:51:36 GMT
Lines: 33

In article <[e-mail]> [e-mail] writes:
>BACKGROUND:
>    IRIX 4.0.5F, indigo xs24.  Using the following to compile:
>cc -I../inc -I. -DNO_PROTO -g -ansi -prototypes -float  -c resource_main.c
>
>I have this program which uses signals.  I have three function
>prototypes which are the signal handlers.  I keep getting errors
>from the compiler telling  me that sigcontext isn't defined anywhere

The cc(1) man page tries to make clear that the preferred (that is,
normal) compilation command is
    cc -xansi -D__STDC__=1
and that
    cc -ansi
is really only for compiler conformance testing.

More than a few people have not understood this so the man page is
obviously not as clear as I had hoped!

My reasoning in setting it up this way was wrong, both in terms
of normal expectations and the ANSI/ISO standard.  Sorry.

This is fixed in IRIX5: there __STDC__ is 1 with -xansi, -ansi,
and -ansiposix automatically.  With -cckr __STDC__ is absent.

Summary: With IRIX4, use cc -xansi -D__STDC__=1  NOT -ansi
         With IRIX5, use cc -xansi               NOT -ansi






#23.  getting "illegal member use" ?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (David B.Anderson)
Subject: Re: "illegal member use" ?!?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 9 Oct 1993 15:16:39 GMT
Lines: 40

In article <292apf$[e-mail]> [e-mail] writes:
>
>I'm getting "illegal member use"'s lately, which I don't understand.
>
>They keep appearing when I add new members to a struct, but they complain
>about an old member of the struct, and only of one, all the others work perfectly.
>
>What's the meaning of this message anyway, when does it appear and how can I get

>A strange fact is the difference between machines.
> When compiling with Ansi C 1.1 under 4.0.5C I get different messages
>from the ones with Ansi C 1.1 under 4.0.5H. Not only different
>messages, but also in different structures.

>P.S.: I'm using cckr-mode.

Try using
    cc -E -Wp,-showdefines
on the two machines and comparing the output.
(-showdefines is documented on the cpp and acpp man pages)

If the two machines have different gl hardware they may have different
gl header files even at the same release level.
Is it possible your structure elements conflict
with something in a header?

Does the spelling of the added member matter?

If the spelling is crucial and -showdefines demonstrates that
the member name does NOT conflict with any #define, it is
probable that you are encountering an old and annoying bug in
/usr/lib/ccom.   If you are able to switch to -xansi -D__STDC__=1
you will not have this problem (I claim :-).






#24.  trouble accessing /debug/nnnnn files via ioctl()
------------------------------------------------------------
Newsgroups: comp.sys.sgi.apps
From: [e-mail] (David B.Anderson)
Subject: Re: accessing /debug/nnnnn files via ioctl()
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 14 Oct 1993 01:50:10 GMT
Lines: 17

In article <[e-mail]> [e-mail] (Philip E. Totah) writes:
>I was trying to access the files in /debug to obtain the prpsinfo struct.
>I've included the source code, the error output and system information.

re: ioctl(fd, PIOCPSINFO, &prpsinfo)

Your program works fine in IRIX5.
It does not work in IRIX4. Sorry.
One way to get the process name given a process id is to do:

    proc_name is an array of char....

    syssgi(SGI_RDNAME,pid,proc_name, sizeof(proc_name)-2);
    proc_name[sizeof(proc_name)-1] = 0; /* just in case
        name was as long as buffer: I want a null terminator */

See
    man syssgi
for more info

This works fine in IRIX4 and IRIX5 (this is what dbx does to
implement the dbx -P flag).






#25.  Lisp still failing with ""contiguous jump problem" in 5.1
------------------------------------------------------------
Date: Thu, 14 Oct 1993 13:11:33 -0800 (PDT)
Cc: [e-mail], [e-mail]

> Our IRIX 5.1 Lisp image (running via the IRIX4 compatibility package)
> is continuing to fail in some very mysterious ways on our Indigo.
>
> Our most pressing need at the moment is to get an explanation for a
> particular message that appears on the console window coincident with
> the Lisp process receiving an "illegal instruction" signal (upon encountering
> what appears to be a perfectly legal instruction).
>
> The message text is:
>
> WARNING: For R4000, too many contiguous jump problems in [new-lisp-no-reorg] pid=19907
>
> Could you possibly make an inquiry and find a detailed description of
> the circumstances triggering this message?  (Or a pointer to existing
> documentation - we have tried and failed to find any references...)
>
The "contiguous jump problem" still occurs in 5.1 sometimes but the
compiler group has reduced the frequency of it.  It has something to
do with a jump at the end of a page to another jump at the end of a
page.  SInce the LISP people are probably generating their own code
on the fly they probably wouldn't now to avoid this.  On 5.1 there is
a compiler option flag to force jumps to always jump to double word
aligned targets.  I think this prevents jumps to the last address
in the page by always jumping to the next to last word in a page instead.

Bottomline its another bug in the R4000 and another reason why SGI wants to
abandon the R4000 in favor of the R4400.






#26.  can't find ELF object file access library
------------------------------------------------------------
Newsgroups: sgi.engr.all
Subject: Re: ELF libraries
Date: 14 Oct 1993 22:20:12 GMT
Organization: Silicon Graphics, Inc.
Lines: 22

|> customer question: do we have an ELF library where customers
|> can call functions to get at pieces of an ELF file? like the symbol
|> table, etc.?
|>
|> Customer claims this is 'standard' part of SVR4.

You need to use /usr/lib/libelf.a . The external interface
to the functions in libelf.a is in /usr/include/libelf.h .



Newsgroups: sgi.engr.all
From: [e-mail] (David B.Anderson)
Subject: Re: ELF libraries
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 14 Oct 1993 23:20:19 GMT

/usr/lib/libelf.a
is in the release.

The SVR4 AT&T UNIX SYSTEM V RELEASE 4 Programmer's Reference Manual
(pub. Prentice Hall) has a section 3E which documents all the elf
calls.  That's the documentation we currently use.

There is, I am told, a bug report on this oversight already.
I will see it gets some attention.






#27.  strange messages from linker
      (vt_Atom_vts: both a large and small symbol)
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (David B.Anderson)
Subject: Re: Strange messages from linker
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 15 Oct 1993 18:57:12 GMT

In article <29fbj7$[e-mail]> [e-mail] ( David Boles) writes:
>I am getting (I believe from the linker) messages of the form:
>
>vt_Atom_vts: both a large and small symbol (possible gp relocation errors ma
>-y result)

This suggests that the equivalent of the following is present:

char vt_Atom_vts[20];       /* in one source file */
extern char vt_Atom_vts[2]; /* in another source file */

This is a no-no.  Don't lie to the compiler about the sizes of things.
An alternative is to compile your code -G 0. This gives up a
very small amount of performance but will eliminate the warnings.


>Warning: gp relocation out-of-range in .text section for relocation entry 1
>-for symbol: BooleanFF_vts

This could be something similar.

These warnings are serious: the resulting a.out will not work.

Add -yvt_Atom_vts  -yBooleanFF_vts
on the link line to see what object files reference these
symbols.






#28.  what is the current version for CC?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.apps
From: [e-mail] (David B.Anderson)
Subject: Re: SGI C++ versions
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 19 Oct 1993 20:08:11 GMT
Lines: 23

In article <[e-mail]> "peter shirley" <[e-mail]> writes:
>We (finally) got our SGI Varsity Pack software, which included
>SGI CC version 3.0.1 (as reported by versions-- see below.  Not to
>be confused with cfront 3.?.?).  I think
>this is a rather old version.  Does anyone know
>how old?  What is the current version?

>output of versions
>I  c++                  10/18/93  C++, 3.0.1

This is the cfront that goes with 3.10.1 compilers. It is
the latest release for IRIX4.

3.0.1 is our product numbering: it is not NOT the numbering
ATT/USL/Novell assign to cfront.  The similarity to ATT
cfront numbering is confusing, I admit...






#29.  Format of pixie(1) trace files?
------------------------------------------------------------
Newsgroups: comp.arch,comp.sys.dec,comp.sys.mips,comp.sys.sgi.misc
From: [e-mail] (David B.Anderson)
Subject: Re: Format of pixie(1) trace files?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 18 Oct 1993 21:31:41 GMT

In article <[e-mail]> salehi@.cs.umass.edu () writes:
>I'm using pixie(1) to generate execution-time instruction
>and data memory reference traces (available with the -idtrace flag).
>
>Does anyone know the format of the trace file pixie generates?
>Is this info off in a MIPS compiler manual?
>
>The man page doesn't mention the trace file format. There is a cryptic
>-[no]oldtrace option which refers to the "old memory reference trace
>format", but the format is not specified.
>Jim Salehi                                  Department of Computer Science
>[e-mail]                         Amherst, MA 01003

The best source I know of is:

Tracing With Pixie
Michael D. Smith
Tech Report  CSL-TR-91-497
Stanford University Computer Systems Laboratory

To get it contact:
                                Naomi Schulman
                          COMPUTER SYSTEMS LABORATORY
                              Stanford University
                            Stanford, CA 94305-4055
                     E-mail: [e-mail]
                                 415-723-1430
                            Hours: M-Th, 8-2 (PST)






#30.  is there an already-compiled version of gcc for the SGI r4k?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.apps
From: [e-mail] (David B.Anderson)
Subject: Re: gcc
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 20 Oct 1993 17:56:14 GMT

In article <[e-mail]> [e-mail] (James Hofmeister) writes:
>DOes anybody know where I can get an already-compiled version of gcc
>for the SGI r4k?  I do not have a C-compiler, so I cannot compile any
>source code.  This was a problem when NFS arrived from SUN as source
>code, and although I was able to get a compiled version of that, it
>would be nice to have a compiler.

gcc won't do you much good. You don't have enough headers, libraries,
or object tools without the develoment option (ido).
ido includes the C compiler.

You need to purchase ido to have a useful compilation environment.






#31.  gp problem:  overflowing the "small-data" area
------------------------------------------------------------
Newsgroups: sgi.engr.all
Subject: customer with gp problem
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 21 Oct 1993 17:26:11 GMT

 > Can anyone assist with this developer's problem?  The company has an
 > innovative 3-D mechanical CAD package that I've been encouraging them to
 > port to SGI, and they've run into what looks like a bad snag.

What has happened is that you have overflowed the "small-data" area,
which is limited to 64K of data, which can be accessed with a
shorter code sequence than is otherwise possible.  The error
"gp-relocation out of range" means that code was generated for a data
item in anticipation of its being able to be place in the small data
region, but it did not in fact fit, hence the generated code has no
hope of working.

What to do? Reduce the number of items which the compiler is trying to
place in the small data area.  How to accomplish this?

Recompile stuff with the flag -G 0.  What is this -G number anyway?
At compile time, it specifies a data-item size.  Data items of that
size or smaller (in bytes) will have code generated for them to be
placed in the "small-data" area.  Data items which are larger will
have code generated which will work regardless of placement.

Thus recompilation of source with -G 0 will prevent *any* data items
from being generated that way.  But sometimes that isn't enough.  You
might also have to install and link against the G0 versions of system
archives.

 > 1) Made sure we were using the latest compiler.  We are using version
 > 3.10 of the compilers and loader on IRIX 4.0.5.

Actually the latest available on 4.0.5 is 3.10.1, but I don't think it
should matter for this problem.

 > 2) Linked our CAD program which also uses the ACIS kernel and a
 > mixture of C and C++.  The CAD program executable also is a slightly
 > larger than the solid server.  It links and runs fine which leads me
 > to believe it is not a size limitation.

Not strictly a size issue, anyway.  See above.

 > 3) Striped most of the code out of the solid server and linked it with
 > minimal calls into ACIS and Hoops.  This version linked and runs
 > fine.  As I slowly add routines back in the loader problem shows up
 > again.  I then removed the routines where the problem started and
 > added some other routines and the problem still occurs so it does not
 > seem to be asscociated with the addition of specific code.

No, it is associated with the accumulation of too much "small data"
By the way, you can find out how much "small data" is associated with
a particular object file thus:

% odump -h filename

the sections marked .sdata, .lit4, .lit8, and .sbss are associated
with small data.  odump -h should report the sizes.

 > 4) I tried linking with -G values of 0, 4, 8 and 10 with no success.
 > The output of each is shown below.  I recompiled all .c and .cxx
 > routines with each "-G" change.

Unfortunately, the linker can't do much based on its -G value other
than figure out where to put commons.  What is needed is a
recompilation.

 > 5) I have generated verbose loader output and loader maps with nothing
 > showing up as obviously wrong.  With the verbose output there are alot
 > of warnings about system routines which show a compiler version of
 > 2.40.  The load map shows all sections are smaller than the CAD
 > executable that links fine.

The warnings about 2.40 may be safely ignored.
 > The various loader errors for -G values are as follows:
 >
 > ****************************************************************************
 >
 > Errors with -G8:
 >
 > GP (null)
 > gp relocation out-of-range for small data or bss by,
 >            2885 in the positive direction,
 >               0 in the negative direction.
It looks like you haven't overflowed by much so perhaps recompiling -G 4
will fix this particular problem






#32.  accessing int, short, char bitfield and alignment issues
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: "David B.Anderson" <[e-mail]>
Subject: Re:  int, short, char bitfields
Date: Sat, 23 Oct 1993 15:38:21 GMT
Lines: 75


DanKarron ([e-mail]) writes:
>>I am trying to template some binary data and
>>does it matter if I use a

>>unsigned short  a : 4;
>>unsigned short  b : 24;
        b:24 is wrong: a short won't hold 24 bits.

>>or

>>unsigned int a: 4;
>>unsigned int b: 24;

Yes it matters with our compilers (ANSI C only defines
the meaning of the int/unsigned int forms: the short/char
bit fields are a common extension).

>>What about alignment issues between ints's and short's ?

Try the following:

struct x {
    char a;
    unsigned short b:4;
    long c;
    char d;
    unsigned int e:24;
    char f;


} y;

void dump(char *cp,int len)
{
    int i = 0;
    for( ; len > 0; --len,++cp,++i) {
        if(i > 0 && (i%4) == 0)
            printf(" ");
        printf("%02x",*cp);
    }
    printf("\n");
}
#define Offsetof(z) ((long) &(z) - (long)(&y))
int main()
{
    printf("offset a %d\n",Offsetof(y.a));
    printf("offset c %d\n",Offsetof(y.c));
    printf("offset d %d\n",Offsetof(y.d));
    printf("offset f %d\n",Offsetof(y.f));
    y.b = -1;
    y.f = -1;
    dump((char *)&y,sizeof(y));
    return 0;
}

Note that b shares the first 16-bits with a. And that e is
aligned after 3 unused pad bytes.

In other words, bit fields obey their 'type'.

Again, this is our practise: code relying on this sort of thing
is non-portable.

If you want to access strangely-aligned data you will find it
easier (and more portable) to use masking and shifting
to access the data.  IMO.







#33.  assembly question:  version stamp
------------------------------------------------------------
Newsgroups: comp.sys.sgi
From: [e-mail] (David B.Anderson)
Subject: Re: assembly question
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 22 Oct 1993 23:13:58 GMT

In article <[e-mail]> [e-mail] (Thuy Mai) writes:
>I have a 3 lines assembly program that I try to understand:
>
>.verstamp 1 0
>.glob g00_
>g00_ = 0x7000000
>
>
>Let assume the above program saved as "g00.s", I try to compile it
>and the result as followings:
>
>as -c g00.s
>    as0: Warning: g00.s, line 2: version stamp does not match
>    .verstamp 1 0

Do cc -S on a hello world program. Look at the .verstamp created.
Change your assembly code to match.

The .verstamp just indicates what compiler release is involved.
IRIX 4.0.5 compilers may have a .verstamp with any of
    2 40    (This one is the base 2.20/2.40 compilers)
    3 10    (this one is the 3.10 compilers stamp)
    3 12    (this one is 3.10.1, the latest for IRIX4)






#34.  how can I access/interpret the stack from within a program?
------------------------------------------------------------
Newsgroups: sgi.engr.devp
Subject: Re: accessing stack from app
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 28 Sep 1993 21:14:01 GMT

On Sep 28,  6:13pm, Kathy Simpson wrote:
> Subject: accessing stack from app
>
> Meaning the ability to dump a textual stack
> trace from an application program.


    One way is to use the abort() system call.
    This will produce a core dump (which has stack trace)
    but it will also exit the program.

    If you want the program to continue executing, then
    you can do this, which is what a number of debug malloc
    libraries do, to make a core file and continue.

        /*
         * fork so child can abort (and dump core)
         */
        if( (pid = fork()) == 0 )
        {
             VOIDCAST write(2,"Child dumping core\n",
                                           (unsigned)19);
             VOIDCAST signal(SIGIOT, SIG_DFL);
             VOIDCAST abort();
        }

        /*
         * wait for child to finish dumping core
         */
         while( wait((int *)0) != pid)
         {
         }



Newsgroups: sgi.engr.devp
From: olson@anchor (Dave Olson)
Subject: Re: accessing stack from app
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 28 Sep 93 23:23:30 GMT
Lines: 26

| We currently have need of functionality available on other platforms.
| Have seen other platforms's source that allow applications access to
| the stack.  Meaning the ability to dump a textual stack trace from an
| application program.

Dave Anderson had a package that allows this under 40x; not supported
but it does work.

This same implementation works under 5.1--see the two programs in
the ~4Dgifts/toolbox/src/swtools/tracebackCode directory.






#35.  ELF/COFF 4.0.5X compatibility library for 5.1.1?
------------------------------------------------------------
Newsgroups: comp.sys.sgi.misc
From: [e-mail] (Martin Knoblauch)
Subject: Re: ELF/COFF 4.0.5X compatibility library for 5.1.1??
Date: 25 Oct 1993 15:14:17 GMT
Organization: Silicon Graphics, Inc.
Lines: 26

In article <2a9taq$[e-mail]>, [e-mail] (Paul
Tatarsky) writes:
|> How are people on the net dealing with the compiler output format
|> change from COFF to ELF under IRIX 5.1 when they still have 4.0.5X
|> machines sharing the source code areas?
|>
|> Or is their something I have missed that lets you generate COFF format
|> files under 5.1.1?

  People can install the irix4 compatibility stuff that comes
for free with IRIX-5.x.y.z (eoe, dev, dev, ftn, c++, etc.). They
than can 'setenv SGI_IRIX4 1' (or the equivalent in your favourite
shell). After that all the compiler related commands use the latest
IRIX-4 compiler tools (3.10.1/3.12).






#36.  times when necessary to use the -static flag when compiling with f77
------------------------------------------------------------
Newsgroups: comp.sys.sgi.bugs,comp.sys.sgi.misc
Subject: Re: fortran compiler bug?
From: [e-mail] (David B.Anderson)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 25 Oct 1993 20:50:02 GMT

In article <mitch.751578732@groucho> [e-mail] (Mitch Baltuch) writes:
>
>we have an application that is running fine on sun workstations, but fails
>on sgi indigo's.  we have traced the failure to a piece of fortran code that
>has been around since 1980 (usgs map projection stuff).  the problem seems to
>be that an area of memory is getting overwritten, munging some parameters
>that are used in projection calculations, causing erroneous results.

If you did not use -static, as in
    f77 -static
on the compile line, please do so.

See the f77  man page on -static.






#37.  what's the difference the abi and irix libs?
------------------------------------------------------------
Re: dev.sw.abi vs eoe1.sw.svr4net versions of lib{socket,nsl}.so??
FYI.  More on the difference between abi and irix libs from the gods.

>> What's the difference between the dev.sw.abi and eoe1.sw.svr4net
>> versions of libsocket.so and libnsl.so?  It looks like they're built
>> from the same source but w/slightly different librarydefs.
>>
>That's a good question. The only ABI differences that I know of
>whould be in the XTI extensions to libnsl. If not then, maybe the
>Mips ABI folks know.

dev.sw.abi is the development environment.
All its libraries go into /usr/lib/abi
All DSO's in /usr/lib/abi are for link purposes *only*.
Consequently, they contain only those symbols that are defined in
the ABI.

When you link a program and want to create an ABI compliant program,
you give cc/ld etc the -abi flag. This causes it to look for headers
in /usr/include/abi first and libraries in /usr/lib/abi. Appropriate
libraries are added to your liblist.

When you execute this abi program, all DSO's that get pulled in are
those in the standard search path (/lib, /usr/lib). eoe1.sw.svr4net
contains the execution environment for both abi and non-abi compliant
programs.

This split up allows us to add more symbols etc in DSOs that are present
in /usr/lib, but not export these to the ABI development environment.






#38.
------------------------------------------------------------